home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000020_csj@iesd.auc.dk _Mon Nov 30 10:54:09 1992.msg < prev    next >
Internet Message Format  |  1996-01-31  |  6KB
  1. Received: from iesd.auc.dk by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA00919; Mon, 30 Nov 1992 03:01:06 MST
  3. Received: from yellow.iesd.auc.dk by iesd.auc.dk with SMTP id AA19169
  4.   (5.65c8/IDA-1.4.4.5 for <tsql@cs.arizona.edu>); Mon, 30 Nov 1992 10:54:09 +0100
  5. Date: Mon, 30 Nov 1992 10:54:09 +0100
  6. From: "Christian S. Jensen" <csj@iesd.auc.dk>
  7. Message-Id: <199211300954.AA19169@iesd.auc.dk>
  8. To: tsql@cs.arizona.edu
  9. Subject: Proposed glossary terms
  10.  
  11. Attached is a handful of proposed terms for the temporal database
  12. glossary.
  13.  
  14. Best regards,
  15. Christian S. Jensen
  16.  
  17. \documentstyle[11pt]{article}
  18. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  19. % VARIOUS MACROS
  20. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  21.  
  22. \long\def\comment#1{}
  23. \newcommand{\entry}[1]{\subsubsection*{#1}}
  24.  
  25. \addtolength{\textwidth}{1.485in}%{1.2in}
  26. \setlength{\oddsidemargin}{.1in}%{.3in}
  27. \setlength{\evensidemargin}{.1in}%{.3in}
  28. \addtolength{\topmargin}{-.85in} %{-1.35in}
  29. \addtolength{\textheight}{1.8in} %{2.8in}
  30.  
  31. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  32. % PAPER START
  33. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  34.  
  35. \begin{document}
  36.  
  37. \subsection{Temporal Specialization}
  38.  
  39. \entry{Definition}
  40.  
  41. {\em Temporal specialization} denotes the restriction of the
  42. interrelationship between otherwise independent timestamps in temporal
  43. relations. An example is a bitemporal relation where facts are always
  44. inserted after they were valid in reality. In such a relation, the
  45. transaction time would always be after the transaction time. Temporal
  46. specialization may be applied to relation schemas, relation instances,
  47. and individual tuples.
  48.  
  49. \entry{Alternative Names}   
  50.  
  51. Temporal restriction.
  52.  
  53. \entry{Discussion}
  54.  
  55. Data models exist where relations are required to be specialized, and
  56. temporal specializations often constitute important semantics about
  57. temporal relations that may be utilized for, e.g., query optimization
  58. and processing purposes.
  59.  
  60. The chosen name is more widely used than the alternative name (+E3).
  61. The chosen name is new (+E5) and indicates that specialization is done
  62. with respect to the temporal aspects of facts (+E8). Temporal
  63. specialization seems to be open-ended (+E4). Thus, an opposite
  64. concept, temporal generalization, has been defined. ``Temporal
  65. restriction'' has no obvious opposite name ($-$E4).
  66.  
  67. \subsection{Specialized Bitemporal Relationship}
  68.  
  69. \entry{Definition}
  70.  
  71. A bitemporal relation schema exhibits a {\em specialized bitemporal
  72. relationship} if all instances obey some given specialized
  73. relationship between the valid and transaction times of the stored
  74. facts. Individual instances and tuples may also exhibit specialized
  75. bitemporal relationships. As bitemporal tuples obtain
  76. transaction-timestamp values during update, updates may also be
  77. characterized by specialized bitemporal relationships.
  78.  
  79. \entry{Alternative Names}
  80.  
  81. Restricted bitemporal relationship.
  82.  
  83. \entry{Discussion}
  84.  
  85. The primary reason for the choice of name is consistency with the
  86. naming of temporal specialization (+E1). For additional discussions,
  87. see temporal specialization.
  88.  
  89. \subsection{Retroactive Bitemporal Relation}
  90.  
  91. \entry{Definition}
  92.  
  93. A bitemporal relation schema is {\em retroactive} if each stored fact
  94. of any instance is always valid in the past. The concept may be
  95. applied to bitemporal relation instances, individual tuples, and to
  96. updates.
  97.  
  98. \entry{Alternative Names}
  99.  
  100. None.
  101.  
  102. \entry{Discussion}
  103.  
  104. The name is motivated by the observation that a retroactive bitemporal
  105. relation contains only information concerning the past (+E8).
  106.  
  107. \subsection{Predictive Bitemporal Relation}
  108.  
  109. \entry{Definition}
  110.  
  111. A bitemporal relation schema is {\em predictive} if each fact of any
  112. relation instance is valid in the future when it is being stored in
  113. the relation. The concept may be applied to bitemporal relation
  114. instances, individual tuples, and to updates.
  115.  
  116. \entry{Alternative Names}   
  117.  
  118. Proactive bitemporal relation.
  119.  
  120. \entry{Discussion}
  121.  
  122. The choice of ``predictive'' over ``proactive'' is due to the more
  123. frequent every-day use of ``predictive,'' making it a more intuitive
  124. name (+E8). In fact, ``proactive'' is absent from many dictionaries.
  125. Tuples inserted into a predictive bitemporal relation instance are, in
  126. effect, predictions about the future of the modeled reality.  Still,
  127. ``proactive'' is orthogonal to ``retroactive'' ($-$E1).
  128.  
  129. \subsection{Degenerate Bitemporal Relation}
  130.  
  131. \entry{Definition}
  132.  
  133. A bitemporal relation schema is {\em degenerate} if updates to it's
  134. relation instances are made immediately when something changes in
  135. reality, with the result that the values of the valid and transaction
  136. times are identical. The concept may be applied to bitemporal relation
  137. instances, individual tuples, and to updates.
  138.  
  139. \entry{Alternative Names}
  140.  
  141. None.
  142.  
  143. \entry{Discussion}
  144.  
  145. ``Degenerate bitemporal relation'' names a previously unnamed concept
  146. that is frequently used. A degenerate bitemporal relation resembles a
  147. transaction-time relation in that only one timestamp is necessary.
  148. Unlike a transaction-time relation, however, it is possible to pose
  149. both valid-time and transaction-time queries on a degenerate
  150. bitemporal relation.
  151.  
  152. The use of ``degenerate'' is intended to reflect that the two time
  153. dimensions may be represented as one, with the resulting limited
  154. capabilities.
  155.  
  156. \end{document}